home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 381 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.7 KB
  1. Path: hecate.umd.edu!ram
  2. From: ram@mbisgi.umd.edu (Ram Samudrala)
  3. Newsgroups: comp.infosystems.www.misc,comp.infosystems.www.authoring.cgi,comp.infosystems.www.servers.misc,comp.infosystems.www.servers.ms-windows,comp.infosystems.www.servers.unix,comp.infosystems.www.authoring.misc,comp.infosystems.www.servers.mac,comp.lang.perl.misc,comp.lang.c
  4. Subject: Re: Unix or NT? Get a Mac!
  5. Followup-To: comp.infosystems.www.misc,comp.lang.perl.misc,comp.lang.c
  6. Date: 4 Jan 1996 22:16:21 GMT
  7. Organization: The Centre for Advanced Research in Biotechnology
  8. Message-ID: <4chjjl$a5j@hecate.umd.edu>
  9. References: <480qej$3h3@sundog.tiac.net> <4cc63m$5gk@hecate.umd.edu> <4ccbg1$ilq@csnews.cs.colorado.edu> <4ch7c6$lrm@cheetah.pacinfo.com> <4chdjn$3mc@csnews.cs.colorado.edu>
  10. Reply-To: me@ram.org
  11. NNTP-Posting-Host: indigo3.carb.nist.gov
  12. X-Newsreader: TIN [version 1.2 PL0]
  13.  
  14. Removing a bunch of groups I find unrelated to this in Followups, and adding comp.lang.c.
  15.  
  16. Tom Christiansen (tchrist@mox.perl.com) wrote:
  17.  
  18. >   Automatic memory management -- no more malloc and free issues, no more
  19. >   overrunning the end of an array or getting a bad pointer, no more line
  20. >   too long problems or "please recompile with a larger X" problems etc.
  21. >   This alone is usually sufficient justification for ditching C for a lot
  22. >   of programs.
  23.  
  24. Thanks for the list.  This is partly an issue of whether you're a
  25. careful programmer or not.   Perhaps it might take a few months of
  26. coding in C to get these aspects right, whereas it might never be a
  27. worry for Perl programmers.  However, it is a function of the
  28. programmer rather than any innate feature of the languages.  Normally,
  29. if you're coding well, these issues should never come up.
  30.  
  31. >   Dynamic typing system -- you don't have to worry about whether
  32. >   something is a 2byte integer or an 8byte float or a constant 5byte
  33. >   string with signed characters or a 20byte string of constant unsigned
  34. >   characters.
  35.  
  36. >   Built-in security models -- the taint checking uses a dataflow analysis
  37. >   to determine what's safe and what isn't that only a very clever global
  38. >   register allocator and pointer tracker could do in C.  This protects a
  39. >   programmer from a nefarious interloper, or his own mistakes.  And the
  40. >   Safe module offers secure compartments for protected execution for when
  41. >   you don't even trust the author of the code.
  42.  
  43. >   Rich standard library -- this offers convenient manipulation of high level
  44. >   objects, including but not limited to strings, regular expressions,
  45. >   numbers, arrays, hash tables (associative arrays), files, and sockets.
  46. >   These objects have no built-in limits regarding their size or content.
  47.  
  48. >   Portability - perl emulates a standard environment even on alien or
  49. >   otherwise bizarre systems where you would have to do things
  50. >   differently.  Perl programs written for Unix, MVS, VMS, Apples, MS-DOS,
  51. >   NT, or AIX can often be ported between each other with a simple
  52. >   copy command and no further munging.  This you cannot do with C or
  53. >   shell.
  54.  
  55. This I think is the biggest advantage of Perl.  
  56.  
  57. >   Both low level and high level usefulness - On one hand, you can write
  58. >   simple, small little hello-world programs knowing nothing but a little
  59. >   shell programming background that work the first time you type them in,
  60. >   but on the other hand, you can write much larger pieces of code in a
  61. >   robust and modular style with public and private parts, interfaces
  62. >   versus implementations etc.  Thus it is accessible and useful to
  63. >   programmers at both ends of the expertise spectrum.
  64.  
  65. >for the task when it gets in your way, bogging down your implementation
  66. >efforts with nitty gritty details.
  67.  
  68. I guess I've never had this problem with the choices I make (usually
  69. C, perhaps a functional language, and sometimes FORTRAN).
  70.  
  71. >I do not believe you can seriously suggest that C is more appropriate
  72. >for text processing purposes than Perl.
  73.  
  74. It depends again---I did tell you to not waste your time implementing
  75. the stuff I sent you (which is largely text processing), but if you
  76. had done so, it'd have taken donkey's years to run with the kind of
  77. inputs I have (which can run into tens of thousands of lines). 
  78.  
  79. In any case, I'm beyond caring now.  I guess ultimately we're going to
  80. use whatever we want and what we're comfortable with.  I use Perl every
  81. so often (mainly for text-processing of small inputs), but that's the
  82. extent I'd use any interpreted language for.
  83.  
  84. --Ram
  85.  
  86. me@ram.org  ||  http://www.ram.org  ||  http://www.twisted-helices.com/th
  87.   Person man, person man. Hit on the head with a frying pan. 
  88.   Lives his life in a garbage can. Person man, 
  89.   is depressed or is he a mess? Does he feel totally worthless? 
  90.   Who came up with person man? Degraded man, person man. ---TMBG
  91.